Security-JAWS 第33回レポート #secjaws #secjaws33 #jawsug

Security-JAWS 第33回のレポートです。知見がいろいろです。セキュリティ対策を諦めない！

#JAWS-UG

#セキュリティ

#レポート

#AWS

臼田佳祐

2024.05.23

こんにちは、臼田です。

Security JAWS 第33回が開催されましたのでレポート致します。

Security-JAWS【第33回】勉強会 2024年5月23日(木) - Security-JAWS | Doorkeeper

動画

後ほど

レポート

Session1: APIGWとLambdaで決済APIをPCIDSSに準拠したお話株式会社ゆめみ砂岡雪さん

そもそもPCI DSSとは？
- クレジットカード決済におけるクレジット会員データを安全に扱うことを目的としたセキュリティ基準
- 12個の要件と6個の目的に準拠する必要がある
なぜAPIGWとLambdaでPCI DSSに準拠することになったのか
- 既存の環境
  - コストが高い
  - 通信経路が分かりづらい
  - 低コストにしてわかりやすくしたい
  - 管理VPC郡とサービスVPC郡がある
  - コストは管理VPC郡に偏っていた
  - VPC PeeringしてPeering先からインターネットに出たりするなど経路制御がある
- APIで画面がいらない仕様
- Lambdaに加えてWAFやRDSなどを使う
- サービスVPCの中にRDSだけは残した
- 管理VPCにVPC Lambdaを作った
- API Gatewayから入ってくる
- ログはCloudWatch
- CloudFrontも入れてこれもログを取りWAFで防御
- LambdaのSecurity GroupはアウトバウンドでRDSと決済代行会社のみにしている
満たしたセキュリティ要件
- PCI DSSの対象環境は決済システムVPCのみ
- RDSは対象外
- WAFでOWASP Top10対応やNISTなど
- ログはCloudWatch Logsへ
発生した問題
- 一部加盟店に提供していた決済用画面が利用できなくなった
  - 無いと言われていたが実はあった
  - CloudFront + S3で対応した
- WAFがPOST通信をデフォルトで拒否
  - 拒否したルールを検知モードに変更した
- マネジメントコンソールへのログインがPCI DSSの対象になった
  - 代替コントロールとしてCloudTrailの監視ログでCloudWatchに流して、6回ミスをしたら通知するように設定した
WAFで使ったルール
- SQL database
- Bot Control
- Admin Protection
- Core rule set
- 他にもいくつかカスタマイズ
リプレースして楽になったこと
- インフラの大部分をフルマネージドにできた
  - AWS Artifactで説明をカバー
- インフラの展開がIaCでできるように
  - コードレビューできる
- 定期スキャニングの対象が開発コードのみになった
  - 4半期に1度のネットワーク層の脆弱性スキャンが免除になった
- 仕様書などの作成資料が大幅に減った
  - 用意すべき監査資料がなくなった

感想

VPCの構成要素を減らしてPCI DSSの監査負荷を減らしたり、費用を削減できるのはいいことですね！真似したいですね。

Session2: イノベーションを加速するためのGRCとAWSセキュリティアマゾンウェブサービスジャパン合同会社執行役員パブリックセクター技術統括本部長瀧澤与一さん

アーカイブ無しです！

Session3: Amazon Cognitoでのパスキー（パスワードレス認証）実装メドレー keikoitさん

資料はこちら

パスキー認証とは
- パスワードを利用しない認証方式
- WebAuthnとCTAP
- 認証器はFIDOなどで決められている
パスキー認証の3つの特徴
- 公開鍵暗号方式
  - 最近は認証器をなくしても、クラウドバックアップから復旧ができるなどの仕組みが出てきている
- チャレンジレスポンス
- 認証器がRPサーバーの識別子に対して署名
  - 中間者攻撃などに耐性がある
NIST SP 800-63Bへの補足
- パスキーに関する補足文章がでた
- 今までは外に出ないからAAL2を満たす感じだった
- クラウドプロバイダが攻撃されたらどうなるかなどの脅威についても書かれている
AWS公式からCognitoでハンズオンがある
- Implement Passwordless authentication with Amazon Cognito and WebAuthn
- Amazon Cognito Passwordless Auth
- カスタム認証フローでLambdaがいろいろやる
- チャレンジと検証をするLambda関数がある
手順
- サンプルコードを使う場合非常にかんたん
- 1-2時間かからない
デモ
- ユーザーIDを手入力してもいいし、ボタンを押すだけにもできる
- ボタンを押してサインインする
- パスキーが2つ登録されているのでそれを選択するようになる
- Macで確認しているが、今回はiPhoneを利用して認証する
- QRコードが表示されて、これをiPhoneでスキャンする
- 入れた
- DynamoDBに最後にいつサインインしたかやパスキーの情報などが保管されている
- 認証方法
  - メインはパスキー
  - フォールバック用でMagic Linkになっている
  - 他にも一般的にはパスワードを許す場合がある
  - しかしフォールバックが脆弱性になることがあるのでパスキーオンリーにしていきたいところだが、ハードルは高い
シーケンス
- リクエストをブラウザ経由でRPサーバーへ
- チャレンジをブラウザに
- 本人確認後認証器で鍵を作成してレスポンス
- サーバーで検証して公開鍵などをDBに保管
- Cognitoでやると
  - API Gatewayが呼び出されてJWTの検証がされる
  - 裏のLambdaで検証してデータをDynamoDBに保管する
  - Cognitoからはカスタム認証のLambdaを呼び出す
  - DynamoDBの中身
    - aaguid: パスキープロバイダーのID
      - 野良のものを管理しないといけないので最近はこれの認証プログラムがFIDOで検討されている
    - flagBackupState
      - クラウド上にバックアップされているかどうか

感想

パスキーいいですね。ワークショップもあってかんたんに試せるのでガンガン使っていきまっしょい！

Session4: Secure Serverless Architecture Fusic 技術本部/技術共創部門清家史郎 (@seike460)さん

サーバーレスアーキテクチャの利点と課題
- サーバレスとはなんなのか
- CNCFによるとサーバー管理を必要としないやつ
- 利点
  - スケーラビリティとかいろいろあるよね
- 課題
  - セキュリティの複雑性
  - トラブルシューティングの難しさ
  - 依存関係の管理
  - コールドスタート
  - ベストプラクティスの進化
  - 特に上2つに今回は向き合う
セキュリティの重要性
- 大事だよね
- 企業の信頼を損ねたりビジネスできなくなる
セキュリティ対策のアプローチ
- 予防
  - 起こらないようにする
- 検知
  - なにか起きてもすぐに検知する
- 対応
- 復旧
対象サービス
- API Gateway
- Lambda
- CloudFront
- S3
- DynamoDB
API Gateway / Lambdaのセキュリティ
- API Gateway
  - リクエストの入口に注目
  - 入口からバックエンドに行けなければ攻撃は成功しない
  - 認証認可
    - API KEY認証
      - クライアントが信用できる場合のみ有効
        
        漏洩すると弱い
      - パブリックに公開されたHTMLやJavaScriptなどへの埋め込みはNG
    - IAM認証
      - セキュアな場所に配置したアクセスキーを利用
      - パブリックNG
      - ローテーションも検討したほうがいい
      - AWS Sigv4を利用する
      - バックエンドに配置するのが一般的
    - Cognitoユーザープール
      - フロントで使うならこれ
      - ユーザープールを使用してJWTトークンを発行
      - JWTを検証してIAM認証する
  - トラフィック保護
    - WAFの導入
    - レート制限とスロットリング
  - ネットワークセキュリティ
    - VPCリンク
      - API GatewayからVPCにアクセスする
    - VPCエンドポイント
      - VPCエンドポイントからVPCにアクセス
- Lambdaのセキュリティ
  - 入口を守るだけではだめ
  - ここもしっかり守る
  - IAMの最小権限を意識する
  - 権限設定(IAMロール)
    - 必要最低限の権限の付与
    - S3バケットへの読み取り権限のみを渡すなど
  - 環境変数の管理
    - KMSによる暗号化
    - AWS Secrets Managerの利用
      - RDSへの接続情報などはここから利用
  - VPC設定とセキュリティグループ
    - VPC Lambdaでプライベートリソースへのアクセスを提供
      - RDSに接続したい場合など
      - コールドスタートとIP数に注意
    - セキュリティグループのベストプラクティス
      - 最小限のアクセスを許可するポリシー設定
      - VPCの通常の運用と同様
CloudFront / S3のセキュリティ
- CloudFrontのセキュリティ
  - オリジンになることが多いS3をどう保護するのか
  - 一番前に立つことになるのでAWS WAFなどで守ることを視野に入れる
  - オリジンサーバーの保護
    - OAI
    - 署名付きURL及び署名付きクッキー
  - HTTPS
    - 証明書を適用する
  - WAFの設定
- S3のセキュリティ
  - S3のアクセスコントロールを適切にする
  - 公開されるHTMLなどに絶対にあくせすきーなどを置かない
  - バケットポリシー
    - アクセス制御する
  - サーバーサイド暗号化
    - SSE-S3
    - SSE-KMS
    - SSE-C
  - ネットワークアクセス制御
    - VPCエンドポイントを利用した限定的なアクセス
    - パブリックアクセスブロック
  - CloudTrailによる監査ログ
  - ログの監視とアラート
DynamoDBのセキュリティ
- データ保護
  - サーバーサイド暗号化
- アクセス制御
  - IAMで最小権限
    - CRUDの細かい権限管理を適用する
  - IAMロールを利用する
- ネットワークセキュリティ
  - VPCからアクセスするならVPCエンドポイントを利用する
- ログとモニタリング
  - CloudWatchとCloudTrailを使う
    - メトリクス、ログ、アラームを活用する
まとめ
- サーバレスになったからセキュリティが上がるわけではない、複雑性は上がる
- 入口を守ることは大事
- どんな属性のものをナンの目的でどこにどのように配置するのかを理解する
- セキュアな運用のためにVPCの利用も検討する

感想

サーバレスを利用してるとコンポーネントが増えて複雑になるので、セキュリティ対策が大変になるということはままありますよね。セキュリティの原則や考え方はいつもかわらないので、理解してやっていきましょう。

Session5: 左手は添えるだけ！？AWS Well-Architected Frameworkが教えてくれる大事なデータの守り方日本電気株式会社クラウド・マネージドサービス事業部門大竹孝昌さん

AWSセキュリティわかる？難しい？
アーキテクチャ設計において大事なデータの守り方を紹介
AWS Well-Architected Frameworkとは
- これ
- ベストプラクティス集
- 6つの柱
- 本当か？
- 個人的にはベストプラクティス集ではない
  - 質問に対するベストプラクティスが色々書かれている
  - しかしリスクに対するあんなやり方がありますと書いてある
  - リスク評価の質問集だと思う
  - 詳しくはJAWS DAYS 2022の動画で
データを守るベスト・オブ・ベストプラクティス
- 実は期待しているベストプラクティスは付録に入っている
- SEC08-BP05 人をデータから遠ざけるメカニズムを使用する
  - データの閲覧や操作をスクリプトやダッシュボードなど間接的なデータアクセスを実現すること
  - 文面を素直に理解するとこの程度だが解釈を工夫する
ベストプラクティスは解釈次第で化ける
まずは守るデータがどこにあるのか把握
- どのサービスがデータを保持するのか？
  - サービスが守り方を決める
  - よくあるデータ保存場所
    - DB
    - ファイル
    - VPC内
    - VPC外
    - サービスへのアクセス経路によっても守り方は変わる
人をデータから遠ざける
- 経路を絞る
  - データソースへのアクセス経路を限定する
    - VPC内ではEC2インスタンスにアタッチされたENIにセキュリティグループがアタッチされる
    - EFSやRDSにもセキュリティグループがアタッチされる
    - セキュリティグループのID同士で紐づけてルールを記述する
    - ルートテーブルでも絞る
- 権限を絞る
  - 人やプログラムごとにアクセス可能範囲を定義する
    - アクセスできるのか
    - アクセスできてもどのリソースにさわれるのか
    - 認証と認可の管理方法はサービスごと異なる
      - RDSだと認証はIAMでもできるが認可はDB側の機能
      - 最近はAmazon Verified Permissionsをアプリケーションの認可に利用できる
    - バックアプデータのアクセス制御も本番データと同じようにする
      - DBのスナップショットがみんなさわれるのはだめ
    - 詳細はAWSのガイド(1次情報)を参考にしよう
- 手段を絞る
  - データの閲覧や操作をツール経由に制限する
    - 踏み台サーバー経由とか
      - ログイン直後に自動でスクリプトが立ち上がるようにして操作を制限する
    - マネジメントコンソールからDynamoDBやS3の中身を見れたり
      - QuickSightからしかデータを見れないようにしたり
    - データアクセスのIAMを利用した時にアラートを出すなどもよし
誰がそのデータにアクセスしているか意識する
- 人やプログラムがデータにアクセスする
- 仕組みを分解すると結局データにアクセスするのはアプリケーションなどのプログラム
人をデータから遠ざけた後
- 痕跡を残す
  - 必要なものはすべて記録せよ
    - 誰がどこに残すのかを意識せよ
      - アクセスする側で残す
      - データストア側で残す
    - RDSならRDS自身で記録できる
    - CloudTrailで操作のログが記録される
    - 自分たちの実装は自分たちでログを保存
- 検知と通知
  - すぐに気づきたいものを選別してアラートを設定
  - EventBridge経由でSNS通知やLambdaでカスタムアクションなど
- 定期的なログ確認
  - 監査が必要
  - 改善していく
  - なんとなく確認は意味がないので具体的なチェック観点を用意する
    - チェックリストは有効性もあるけどチェックリストのことだけしかやらなくなったりする
    - 使い手次第
まとめ
- アーキテクチャ設計編
  - 経路を絞る
  - 権限を絞る
  - 手段を絞る
  - 証跡を取る
- システム運用編
  - 定期的なログ確認
  - 設計や運用の改善

感想

分解していくとよく理解できますね。しっかりやっていきましょう！

Session6: [クラウドZoom相談] 当日のslido & ドアキで受付けた質問に回答する枠 Security-JAWS運営メンバー

EOL管理とかが流行ってますが、EOLが問題というよりは脆弱性が放置されているのが問題なんだと思う。EOLすぎたけど新しい脆弱性がないって場合のリスクは、新しい脆弱性が報告された時に、対応できない（しにくい）という認識で良いですか？

脆弱性にフォーカスした質問だが、そもそもEOLになるとその仕組みが周りに影響がある
- 周りのアップデートを妨げたり
- EOLしたものは置き換える必要がある
そもそもEOLしているものを抱えること自体がリスク
サポートも受けられない

Security HubやAWS Configとかで権限が強すぎるとかSGがガバガバすぎるのを、数十のアカウントに対してスキャンして結果を確認するのが辛いんですが、その辺を楽にできるツールなりSaaSとかってどんなのがありますか？

対応していくうえで再度出てくることを防止する必要がある
- 作り変えていく
そもそもこれが辛くなるなら会社の仕組みを変える必要がある
- ガイドラインやルールを整備する
- 現場への教育をする
- 現場にセキュリティの責任をもたせる
- これを徹底して回すと辛くないはず
- そうなるとツールは何でもいい
SREに全部の責任が押し付けられるのは違う
この問題はCSPMなどサードパーティのツールを入れるだけでは解決しない
検出タイミングも遅い
- 開発段階でそれを検出して直せるようにしていく必要がある